home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus 2000 #5 / Amiga Plus CD - 2000 - No. 5.iso / Tools / Misc / EZHome / Readme < prev    next >
Text File  |  2000-01-01  |  7KB  |  140 lines

  1. July 18th, 2000, the Heskett Ranchette in WV, USA
  2. With further updates as I swat ever smaller bugs in the 1.00 release
  3. Last update July 18, 2000 Gene Heskett
  4.  
  5. This is the version 1.00i upgrade package for registered users prepared by
  6. Gene Heskett, half of the EzSoft team.  Unforch, Jim's machine seems to
  7. have passed on, so I'm the remaining 'it' for EzSoft :)
  8.  
  9. cd to your 'EzHome:' assign and unpack this right over the original
  10. install, or rename the files EzHome and EzHomePrefs by appending their
  11. version numbers to the name if you'd like to save them for posterity,
  12. whatever that is.
  13.  
  14. 1. You will now find that the housecodes that didn't work, now do.  You'll
  15. also note that the housecode in the gui display is actually updated from
  16. the status data fed back to the gui from the daemon, so that it will show
  17. properly in the gui even if you grab a shell and give the daemon a command
  18. like "rx 'address ezhome sethouse p'", even if you do it while the gui
  19. isn't running.  The initial status update the gui asks for will update it
  20. to the current housecode in both displays.
  21.  
  22. One thing that may not be readily apparent is that the RealTime page, the
  23. front page if you will, can issue commands to other housecodes besides the
  24. one the prefs page is set at.  Only by changing it from a cli, or from the
  25. prefs page, is the cm-11a's actual house monitor updated.  I update the
  26. RealTime page too, unforch without updateing the button labels in the left
  27. column.  That might be in V1.01 if its easily done. The GUI is another
  28. animal entirely :)
  29.  
  30. 2.  You will now find your registered name is displayed by the about
  31. requester, the 'house' icon in the upper right corner of the gui being the
  32. button for that.
  33.  
  34. 3. Somewhere along the line, the daemons quick mode was commented out, so
  35. that probably doesn't work.  I've never run it that way myself, and it is
  36. designed to be a background daemon waiting to do your bidding anyway.
  37.  
  38. 4. Late fixes to the daemon include the detection of the word 'RUNIT' in
  39.     the descriptor portion of the EZHome:prefs/Action.prefs file
  40.     While testing it here, I kept getting guru's from 'SPEAK' because
  41.     it was trying to be a whole committee meeting with several copies
  42.     of talkingclock trying to get to it at the same time.  So a new
  43.     'VARIABLE' has been added.  If the function IS safe to run multiple
  44.     copies of itself, then add the keyword 'RUNIT' to the end of the
  45.     description and resave the prefs.  If it is not safe to run
  46.     concurrant copies of the command, the daemon will now WAIT for
  47.     the command to execute before continueing.  As some commands might
  48.     be lengthy scripts, thereby holding up the daemon till they return,
  49.     it is probably better to have the script set a small file in RAM:
  50.     to indicate to other copies that may be launched that it is already
  51.     running, and if it finds it, before it sets it, it should exit.
  52.     The original copy of course needs to delete that tallying file as
  53.     the last thing it does before quiting.  This doesn't actually
  54.     require a lot of code to do.  Here is one way to do it.
  55. -----------------------
  56. /*  AREXX requies the FIRST line to be a comment line */
  57. /*    ARexx script to prevent more than one copy of 'unique_name' from being run */
  58.  
  59. SIGNAL ON BREAK_C /* make it breakable via ctl-c */
  60. options results
  61.  
  62. mytest = 1 /* set this to 0 to run your script or program instead of my test delays */
  63. runfile    = 'ram:unique_name'    /* change to suit human readability */
  64.  
  65. /* most arexx stuff needs this, make sure its already in memory */
  66. IF ~SHOW('L','rexxsupport.library') THEN CALL ADDLIB('rexxsupport.library', 0, -30)
  67. IF ~SHOW('L','rexxdossupport.library') THEN CALL ADDLIB('rexxdossupport.library', 0, -30)
  68.  
  69. IF ~EXISTS(runfile) THEN DO
  70.     ADDRESS COMMAND 'date >'runfile
  71.     IF mytest = 1 THEN DO
  72.         CALL DELAY(1500) /* 30 secs to test the rest of the routine */
  73.     END
  74.     ELSE DO
  75.  
  76. /* "include" your original arexx script here with your favorite editor
  77.    one could also run something else with the usual
  78.         ADDRESS COMMAND name_of_program (or shell script) to be run here
  79. */
  80.     END
  81. END
  82.  
  83. BREAK_C: /* fall thru to clean house, or if broke with ctl-c */
  84. ADDRESS COMMAND 'delete >NIL: 'runfile
  85. EXIT 0 /* all done, quit this instance W/O error */
  86. -----------------------
  87.  
  88. 4a! The most recent change is to treat something being sent to itself as
  89.     a RUNIT item regardless of whats in the prefs file comment.  Prevents
  90.     lockups in the situation where it is sending a message to itself,
  91.     but waits forever at the send point for a receipt it will never get,
  92.     being stuck at the 'send it' point waiting.  This, as of July 2, has
  93.     been fine tuned a bit as I found it was arbitrarily running anything
  94.     located in the EzHome: assign, not what I wanted at all.  So it now
  95.     checks the string comparisons against the full 'ADDRESS EZHOME',
  96.     requireing a return of greater than 4 before that behaviour is
  97.     triggered.  Since a normal commandline string also is prefaced
  98.     with 'RX "ADDRESS EZHOME"' which returns a 5 when queried with
  99.     POS(search,target) this seems pretty safe.  Version is now 1.00h.
  100.  
  101. 4b!    A couple of fixes for a runaway send, and it now logs in 3 places,
  102.     once for an arexx received command, once for a powerline received
  103.     command, and again for a powerline sent command.  If the logfile
  104.     level is 2, it also logs Action.prefs about to be done as of V1.00i.
  105.  
  106. 4c! I've noted that we don't really specify the contents of the file
  107.     "EZHome.prefs", so here is my current one with added comments:
  108.  
  109.     comment                            line in file    content of fileline
  110. Location to save logfile to                1            sd0:ezhlog.txt
  111. Serial devices name                        2            duart.device
  112. Serial device unit number                3            0
  113. Default house code number                4            6
  114. Logfile detail level                    5            2
  115.  
  116.     Just 5 lines, located obviously in the EZHome:prefs directory.
  117.     Line 1-3 are self-explanatory.  Here I can run it on the seriel.device
  118.     just as easily, but I had this spare port on my Multiface III since my
  119.     networking uses an ethernet card to my linux box, which still auto-dials
  120.     when this machine wants online :-)
  121.     Line 4 is the housecode as decoded, that 6 equals house A.
  122.     Line 5 if = 1 will cause what it has done to be logged, if 2 will cause
  123.     it to also log what Action.prefs it is *about* to do.  This is for
  124.     V1.00i and greater only, a troubleshooting aid.  The extra logging will
  125.     slow it down because it will be between the event coming in and the
  126.     actual performance of the Action.prefs event.
  127. 4d!    Un-mentioned are troubleshooting outputs obtainable when ezecuting
  128.     the daemon from a shell. 'ezhome -v' will get you a LOT of output as
  129.     it sort of self traces its execution, including the line number in
  130.     the source code, please report these if possible.
  131.  
  132.     A late addition is a second 'ezhome -s' option which will trace only
  133.     the powerline reception and handling code, and will, when it does a
  134.     readprefs, also output the Ezhome.prefs lines, but only in that code
  135.     built *after* 07-15-2k will the prefs be read back, thats why it
  136.     grew about 80 bytes.
  137.  
  138. 5. Beat on it and give me feedback please, addressing flowers and flames
  139.     to <gene_heskett@iolinc.net>
  140.